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Abstract. This paper presents Privilege Calculus (PC) as a new ap- 
proach of knowledge representation for Separation of Duty (SD) in the 
view of process and intents to improve the reconfigurability and trace- 
ability of SD. PC presumes that the structure of SD should be reduced 
to the structure of privilege and then the regulation of system should be 
analyzed with the help of forms of privilege. 



1 Introduction 

The Separation of Duty (SD) is a security principle that is used to formulate 
multi-person control policies, which requires that two or more different people 
be responsible for completion of a task or a set of related tasks [1]. The Role- 
Based Access Control (RBAC) system is defined by a state machine model and 
characterized by the fact that a user's rights to access objects are defined by the 
user's membership to a "role" and by the roles' permissions to perform operations 
on those objects [2]. Hence, the role is a semantic referent of duty representation 
and the structure of role is a division of rights in cross-organization systems. 
With the help of assignment operation, the user-role assignment can be handled 
by one while permission-role assignment is handled by another [3] . 

Because the permission assignment on role hierarchy is static, Sandhu [4] 
introduced the Role Activation Hierarchy (RAH). RAH extends the permission- 
usage hierarchy and makes the role activation governed by an activation hierar- 
chy. Sandhu argued that the administration of RBAC must itself be decentralized 
and managed by administrative roles. Moreover, Ferraiolo [5] argued that static 
separation of duty enforces constraints on the assignment of users to roles, and 
dynamic separation duty places constraints on roles that can be activated within 
or across a user's session. 

Although the delegation model [6] is helpful to resolve the temporal per- 
mission assignment problem by the delivery of duty in trust, the permission 
delegated has to crosscut two or more roles in RAH and the definition working 
to map between them is not easy. Also, for the constraints in RBAC, there is 
an inconsistency between the access control policy and the constraints that are 
specified to limit this policy. One transform limit may preclude, by a constraint. 
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the change in another transform Umit even though the rights that embody the 
conflict have not been assigned yet [7]. So extra mechanisms were integrated to 
detect [8] and resolve [9] the conflict. Jaeger has argued that since fail-safety 
is often a goal of secure systems, some form of conflict resolution may not be 
unreasonable, but the trade-off is not clear-cut [7] . 

It is the question that how to keep change of condition predictable and how 
control exists after reconfiguration in dynamic way, for which the essential chal- 
lenge is, we believe , the representation of SD still. Our approach is enlightened 
by TT-calculus that makes process reconflgurable [10] , and assumes that the duty 
is composed of the interaction commitment of process, i.e. privilege(see section 
3.3), and the result of SD is a collection of interaction commitments, i.e. regula- 
tion(see section 2). The examples in section 5 show the flexibility and usefulness 
of our approach. 

2 Regulation 

There are two synchronized complementary actions in an interaction [10]. The 
guarded action is an action with one preceding action that has not been reduced. 
We have two processors that execute these actions respectively. These actions 
represent the semantics of this interaction of the two processors. 

A component is featured with the composition of distinct functions and con- 
sists of corresponding processors. One fimction features one processor in design, 
and one processor runs one action in one process (runtime). The sequence of 
observed action represents a process and reflects the implementation of function 
intention. So the sequence of programmed action represents an interaction com- 
mitment. Moreover, the intersection of interaction commitment involved in an 
interaction are not empty. 

Although component is neutral, system works in a conservative way. The 
framework of system is a guarding processor and guards each interaction of 
two managed components. The guarding interaction of framework precedes the 
guarded interaction of component. 

Regulation of system is a collection of interaction commitments, including 
the interaction commitments of framework and of component. For the systems 
based on privilege calculus, the result of separation of duty is regulation, i.e. a 
collection of privilege. 

3 Structure of Privilege 

In this section, we give the striicture of privilege with the help of notions, em- 
ployment and condition. The notion of employment is the refined structure of 
function intention. 

3.1 Employment 

Definition 1. The function- entity employment f /e means that function f is 
employed on entity e. 



Proposition 1. There are employments, fi/ei and f2/e2, 

fi/ei + hle2 = ^ /i/ei = A /2/e2 = 



Then we introduce the left employment mergence of function-entity. 
Proposition 2. There are employments, /i/ei 7^ and /2/e2 7^ 0- 




Definition 2. F is a collection of Junctions, and E is a collection of entities. 
The employment F/E is a set {//e|/ e F, e € E}. 

Let F, Fi, and F2 be respectively a collection of functions, and let E, Ei, and 
E2 be a collection of entities. We have /i & Fi, f2 £ F2, ei & Ei, and 62 £ £^2- 
The mergence of employment is 



For the convenience of computation, we give F/0 = 0, 0/i? — and 0/0 = 0. 
If no confusion arises, these expressions, //e, {/}/e and // {e}, are the same as 
{/} / {fi}- With definition 2 and equations 1 and 2, we prove that the employment 
are associative, commutative and distributive. 

3.2 Condition 

Regulation is different from process, which we have discussed in section 2. The 
condition acts as the connection with the state of "process world" . In this sub- 
section, wc propose the definition of condition. 

Definition 3. The fact set T is a collection of subsets of statement collection 
S. The fact set T on S has the following properties: 

1. and S are in T . 

2. The union of the elements of any suh- collection ofT is in T. 

3. The intersection of the elements of any finite sub- collection ofT in T. 

Definition 4. Fact set T on S, condition r is a function r : Tg ^ {IjO} with 
the property: Vxi, X2 & T and xir\X2 = 0, r{xi U X2) = r{x-i) V r{x2)- 

The {1,0} is the true value. If the fact x £ T, we call that the condition r is 
supported on the fact x, or the fact x supports the condition r. 

Proposition 3. For fact set T on S, \lx\,X2 G T and x\ C X2, r{x\) — > r{x2) ■ 

Definition 5. For fact set T on S and condition r, if r{x) is true, the fact 
X gT is the evidence to r. 

Definition 6. For fact set T on S, 3x* G T and such that x* is the evidence to 
the condition r, if -^x C x* and such that x is the evidence to r, then the x* is 
the minimum evidence to r. 



Fi/Ei * F2/E2 = {/i/ei * /2/e2 7^ 0} . 



(1) 



The composition of employment is 



Fi/Ei + F2/E2 = {/i/ei ^ V /2/e2 ^ 0} . 



(2) 



3.3 Privilege 

Definition 7. For a collection of functions F, a collection of entities E and a 
collection of conditions R, the privilege is {F/ E, R) . 

For convenience, we define, (0,r) = 0. 

Definition 8. The privilege space V is a collection of subsets of P with the 
following properties: 

1. (Privilege Mergence) For all privilege, u,v G V, u = {f\/E\,Ri), and v = 

{f2/E2,R2), 

u*v^ {(/i * f2/(Ei n E2),Ri n R2)} ; 

2. (Privilege Composition) For all privilege, u,v G V, u = {fi/Ei,Ri), and 

V=if2/E2,R2), 

u + v = {ifi/E,,R,)U{f2/E2,R2)} ; 

3. For all privilege, u,v gV, u* v = v * u; 
4- For all privilege, u,v gP, u + v = v + u; 

5. For all privilege, u,v,w G V . {u * v) * w = v * (u * w); 

6. For all privilege, u,v,u) G V , {u + v) + w = v + {u + w); 

7. For all privilege, u,v,w G V , u* {v + vu) = u*v + u*w. 

4 Normal Form of Privilege 

Definition 9. The employment arrangement M is a finite collection of employ- 
ment and such that Vro, n G M, m ^ n Am* n = $. 

Definition 10. To employment arrangement M , the normal form of privilege 
p is 

M M 

n£mM(p) = = '^{fi/Ei,Ci) , 

i i 

where fi/Ei is an element of M and Ci is a condition. 

Proposition 4. To employment arrangement M, every privilege is structurally 

equal to its norm,al form. 

Definition 11. To employment arrangement M, the privileges are structural 
equivalence, if and only if they have the same normal form, 

u = v <^==> nfmM(w) = n.imM{v) . 

When one condition has an evidence, these privileges that involve the condi- 
tion are pulsed. Corresponding to normal form of privilege, there is the pulsed 
form. 



Definition 12. To employment arrangement M, on the fact t G T, the pulsed 
form of privilege p is 

M 

pimM{p,t) = ^{fi/Ei,Ci{t)) , 

i 

where fi / Ei is an element of M and Ci is a condition. 

We have a sequence of fact Q = {to,ti, . . . ,tj, . . .). We get the sequence of 
pulse to privilege t, 

pfni^f(jAQ) = (pimM(p,to),pimM{p,ti), . . . ,pimj^{p,tj), . . .) . 

This sequence of pulsed form describes the trace of process about privilege p. The 
trace matrix (cij) of privilege p is made from this sequence, where Cij S {1,0} . 





to ti . 


. tj ... 


fo/Eo 


Co,0 Co,l . 


. Coj . . . 


h/Ei 


Cl,0 Ci,i . 


• ClJ . . . 


fi/E, 


Ci,0 Ci^i . 


■ Cij . . . 


fn/En 


^n,0 ^n,l ' 


■ CnJ . . . 



For example, we have two operations (privileges) opi and op2, and three 
people (privileges) ui, U2 and u^. Wc want to know what will happen at time 
(facts) to and ti. So we define a gauging privilege, g = (wi +W2 + W3) * (opi + 0^2)- 
And the sequence of pulse is {pfm!^{g,to),pfni]^{g,t-i)). 

Definition 13. To employment arrangement M, privileges, u and v, are con- 
gruent on fact t gT, a ^ b, if and only if u and v have the same pulsed form. 

Definition 14. To employment arrangement M, on fact t G T, privilege p is 
compliant to privilege q, p*- q, if and only if {p*q) ~ g. 

The congruence ~ and the compliance *^ are a function PxPxT^ {1)0}. 

So they can be a condition in one high-order privilege. For a compliance example, 
we have the privileges, g, p and q, and such that g = [pt^g]. We call that the 
privilege 5 is a high-order privilege of p and q. 

5 Discussion 

In general, the role-based models, such as RBAC reference model [11,5], AR- 
BAC [12], and T-RBAC [13], have constructs, such as, USERS, ROLES, OPS 
(operations), and OBJS (objects), and relations, such as U A (user-to-role assign- 
ment), PA(permission-to-role assignment), PRMS (set of permission), and RH 



(role inheritance relation). These constructs are able to be defined with privilege 
and these relation with privileges. And these privileges are glued by privilege's 
operations, such as privilege mergence and privilege composition. 

The following code is a demonstration written in PAL (Privilege Analysis 
Language) that is a reference implementation based on privilege calculus. With 
this demonstration we discuss cases about privilege representation. 



namespace "example" { 

let docl is TechDoc 

reader := (read + list) /TechDoc 

meinager := (reader + write + remove) /TechDoc 

bob := reader + write/TechDoc 
may := manager 

phone := read + list 

officepc := read + list + write + remove 

} 



Shown by the above code, wc have four operations, read, list, write, and 
remove, two roles, reader and manager, two users, bob and may, and two termi- 
nals, officepc and phone. The statement "let" declares that docl is a document 
in the category TechDoc. The role reader can read any documents in TechDoc 
and list entries of those, and the role manager can write and remove any one 
in TechDoc and manager inherits all of reader^s privileges that are limited in 
TechDoc. User bob plays the role reader and User may has the role manager. 
The mobile phone, a terminal device, has a limitation to access, read and list. 

So far, wc have defined these privileges: read, list, write, remove, reader, 
manager, bob, may, of ficepc, phone, docl, and TechDoc. 

While user bob has logged in system at his officepc, and the system creates 
his session, sessioni = bob * officepc. In sessioni, bob is able to read, list and 
write any one in TechDoc. 

Later bob uses his personal phone to navigate the system, the session2 is 
created automatically, session^ = bob * phone . The session2S privileges are 
different from sessioni s. We set an employment arrangement, M = read + 



list + write + remove. Thus, 



sessiorii = bob * officepc 

= {reader + write /TechDoc) * {read + list + write + remove) 

= read/TechDoc+ list/TechDoc+ write /TechDoc , 
session2 = bob * phone 

= {{read + list) /TechDoc + write) * {read + list) 

= read/TechDoc + list /TechDoc . 

With the above computation, we know the session2 lacks the employment ^write' 
on TechDoc. It is interesting that the session in system can be created as a 
privilege and these constructs, such as session, user, role, permission, group, 
location etc., could be represented by privilege. 

We continue the story. User bob wants to read the document docl that is a 
TechDoc. The guard readguard to the action read is 

readguard = read * [sessioni *^ {read/docl)] . 

The readguard is the high-order privilege of sessioni and read/docl. The pulse 
of readguard depends on the sessioni 's compliance to read/docl. 

User may has logged in, and her session is session^. She wants to write the 
document rfocl. The rcgidation docs concern not only may's privilege but also 
the rfocl's. So the privilege docl is redefined, docl ~ readable+writable. Because 
the docl's "writable" action and the may's "write" action are complementary 
in this synchronized interaction, writeguard and writableguard are defined, 

writegurad = write * [session^ ^ {write/ docl)] , 
writableguard = writable * [docl ^{writable)] . 

Thus, we have the interaction guard interactionguard, 

interactionguard = writeguard + writableguard . 

Finally, the session^^s compliance and the docVs compliance consistently make 
the pulse of interactionguard. 

6 Conclusion 

Separation of duty is critical not only in security control but also in modeling and 
monitoring of business logic. For improving reconfigurability of representation 
of duty, we propose privilege calculus. With the help of privilege's normal form 
and pulsed form, we are able to analyze the structure of privilege and to monitor 
the change in process. We also have demonstrated that the access control model 
based on privilege calculus is compatible with RBAC, ACL. 



So far, we have only begun to explore the computation of privilege and rep- 
resentation of regulation in access control logic. But we have little knowledge 
about the relationship among regulation, business process and business rule. On 
all accounts, we hope that the paper will throw some light on the knowledge 
representation in separation of duty domain to facilitate the analysis of business 
rules and business processes. 
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